Approved For Release 2ofi§|iEfi£{tl-lMp84-00780R(»)lfe(S)0^)(?30-1 I . 4 h-:*n) 

T - AJ'A'Ur..-- 

FILE 


1 9 MAY 1966 


MEMORANDUM FOR THE RECORD 
SUBJECT: Information Requirements 
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1. On Wednesday, 11 May 1966, I met with Emmett Echols, 


25X1 


to discuss the need to develop and define requirements for 


and 

management information which they would like to have satisfied by new systems 
we are in the process of developing. The problem of defining what is meant by 
"requirements definition” is almost as difficult as defining the requirements 
themselves. All of the teachers, all of the lecturers, and all of the literature 
advocate definition of requirements as among the first steps in the conduct of 
any system study and they all insist that this must be done by the highest 
levels of management. Apparently this has never been done successfully and 
I have been able to find no guidance for setting about it systematically. I 
have attended two seminars at the Civil Service Commission recently which 
were described as intending to deal with the development of management 
reporting systems, the definition of organizational objectives, and the deter- 
mination of requirements. These were reiterations of the need to define 
requirements but none of the speakers had any specifically useful suggestions 
about how the problem of getting it done should be approached. 


2. I explained these problems as background for the discussion and 
hopefully leading to the point that we are trying now to define our requirements 
for information in a way which has never been done before. We know what the 
requirements for computer output are now in the existing systems and we are 
not seeking at this time a redefinition or validation of those. Very often people 
who are asked to define requirements tend to think in terms of particular out- 
put formats for presentation of data or they tend to try to frame their statement 
of requirements in terms of what they believe the computer may be capable of 
producing. It is extremely difficult to avoid these tendencies and the difficulties 
were evident during this discussion. We are interested in requirements for 
information which will permit the Offices to develop their programs, plans, 
and forecasts; measure their accomplishments toward the achievement of 
their plans and objectives; project trends; surface problems; anticipate back- 
logs; as well as provide for feedback, evaluation, and control of resources. 
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3. Mr. Echols asked how I thought they should go about this and I 
suggested that they might begin with the statements of their objectives as 
set forth in the combined program call. In most cases these are very broad 
and general, and sometimes platitudinous. To begin with, the statements of 
objectives will require that they be brought much more sharply into focus and 
brought into the form of some precise statements of specific goals capable of 
achievement within a limited measureable time frame. In addition, I suggested 
that they might review their statements of mission and functions as included in 
the Agency regulations and ask themselves what management information they 
need to fulfill their responsibilities. I also suggested that they try to think in 
terms of the performance criteria for subordinate levels in their organization, 
not in the fitness reporting sense, but in terms by which the success or failure 
of subordinate operations may be measured. For example, the success or 
failure of the recruitment effort may be measured in terms of the number of 
people interviewed, the number put in process, the number entered on duty, 
or some combination or comparison of these and other elements. We need to 
know the kinds of information they want the system to produce in order to make 
these evaluations and it may be useful for them to think about their requirements 
in these terms. I emphasized that they should not attempt to phrase their 
requirements definition in terms of what they may think the computer can or 
cannot do but should simply say what they want the system to produce, then we 
will assume the responsibility for recommending whether or not the require- 
ments can be satisfied manually or automatically. Mr. I [ agreed to 
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produce some requirements at least as a first cut as soon as he can. 


Special Assistant to the 
Deputy Director for Support 
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